Возможно, некоторые администраторы VMware vSphere попадали в ситуацию, когда один из датасторов в виртуальной инфраструктуре оказывался не привязанным ни к какому хосту ESXi, но при этом у него также была неактивна опция Delete Datastore из контекстного меню:

Paul Braren написал полезную инструкцию у себя в блоге о том, как решить эту проблему.

Такой зомби-датастор можно удалить только из базы данных vCenter Server Appliance (vCSA), поэтому вы полностью должны быть уверены в том, что он не используется никаким из хостов, а также в том, что он не презентует никакое физическое устройство в вашей инфраструктуре.

Первое что вам надо сделать - это включить доступ к vCSA по SSH (картинки - отсюда):

Далее нужно зайти по SSH на vCSA, запустить там шелл командой shell и далее запустить утилиту psql для работы с базой данных следующей командой:

/opt/vmware/vpostgres/current/bin/psql -d VCDB -U postgres

После этого нужно найти id датастора следующей командой:

Когда вы нашли id, нужно удалить упоминание об этом датасторе из таблиц базы данных vCSA следующими командами:

DELETE FROM vpx_ds_assignment WHERE ds_id=3089;
DELETE FROM vpx_datastore WHERE id=3089;
DELETE FROM vpx_vm_ds_space WHERE ds_id=3089;

При выполнении второй операции вы получите следующую ошибку:

ERROR: update or delete on table "vpx_datastore" violates foreign key constraing "fk_vpxspace"
DETAIL: Key (id)=(3089) is still referenced from table "vpx_vm_ds_space".

Не обращайте на нее внимания и выполняйте третью. Затем нужно перезагрузить vCSA и снова выполнить второй DELETE, который в этот раз должен завершиться успешно. После этого датастор пропадет из списка в vSphere Client.

Помните, что выполняя данную операцию, вы должны понимать, что именно делаете:)

На блогах VMware вышла отличная статья про безопасность виртуальных машин и виртуальной инфраструктуры VMware vSphere в целом, расскажем ниже ее основные моменты.

Как известно, одним из действенных способов атак на виртуальную инфраструктуру vSphere является проведение злоумышленником вредоносных действий из виртуальной машины, которая потом уничтожается, часто не оставляя следов и записанных действий. Еще один интересный способ со спецификой виртуализации - украсть виртуальную машину (например, контроллер домена) и ковыряться в ней уже в своей песочнице, чтобы вытащить нужную информацию.

Для предотвращения подобных типов угроз есть такие специализированные средства, как VMware Carbon Black, vRealize Log Insight и vRealize Network Insight, но базовые требования информационной гигиены нужно соблюдать и на уровне гостевых систем.

На этом уровне важной составляющей является пакет VMware Tools, имеющий широкие возможности доступа к виртуальной машине - ОС и приложениям. Управление поведением тулзов происходит с помощью вот этих утилит:

• C:\Program Files\VMware\VMware Tools\VMwareToolboxCmd.exe (Windows)
• /usr/bin/vmware-toolbox-cmd (Linux)

Само собой приведенные ниже рекомендации - это руководство для параноиков (но, как говорит Эндрю Гроув - выживают только параноики), потому что безопасность, как вы знаете - это всегда компромисс между удобством и маниакально-призрачным ощущением защищенности.

И вот тут рекомендуется принять во внимание следующие факторы на уровне VMware Tools:

1. Отключить синхронизацию времени с хостом VMware ESXi

Время - очень важная категория в контексте безопасности. Оно важно для логов, для синхронизации событий аутентификации и прочего. По-хорошему, гостевая ОС должна получать время от NTP-сервера, а не от ESXi, который может быть скомпрометирован. Если вы сомневаетесь, что у вас настроено иначе, нужно принудительно отключить синхронизацию времени с хостом. Делается это следующей командой:

VMwareToolboxCmd.exe timesync disable

2. Отключить автообновление VMware Tools

Если у вас в компании принято, что рабочий процесс обновления системных компонентов должен быть унифицирован и контролироваться из одной точки, то можно отключить автоапдейт VMware Tools. Делается это так:

VMwareToolboxCmd.exe config set autoupgrade allow-upgrade false
VMwareToolboxCmd.exe config set autoupgrade allow-add-feature false
VMwareToolboxCmd.exe config set autoupgrade allow-remove-feature false

3. Отключить возможность кастомизации ОС при клонировании

Такая опция позволяет изменять параметры виртуальной машины и гостевой системы, что может быть выгодно злоумышленнику. Отключить кастомизацию ВМ можно следующей командой:

VMwareToolboxCmd.exe config set deployPkg enable-customization false

4. Контроль над информацией, предоставляемой через Appinfo

Об интерфейсе Appinfo мы писали вот тут (он же Application Discovery). Он позволяет, например, собирать информацию о запущенных приложениях внутри гостевой системы (по умолчанию сбор идет каждые 30 минут, это настраивается). 

Отключить Appinfo в виртуальной машине можно следующей командой VMware Tools:

VMwareToolboxCmd.exe config set appinfo disabled true

5. Отключить Guest Operations (оно же Invoke-VMScript)

Командлет Invoke-VMScript - это мощный механизм для разработчиков, позволяющий работать с гостевой системой виртуальной машины со стороны механизма сценариев PowerCLI. Очевидно, что этот интерфейс расширяет поверхность потенциальной атаки, и если вы им не пользуетесь, то его лучше отключить. Делается это следующей командой:

VMwareToolboxCmd.exe config set guestoperations disabled true

6. Отключение ненужных компонентов

Это базовое правило - чем меньше компонентов VMware Tools у вас установлено, тем меньше вероятность, что через какой-то из них произойдет атака. Например, не всем пользователям и администраторам нужны такие возможности, как Service Discovery, AppDefense и Shared Folders. Но здесь, очевидно, нужно соблюдать разумный баланс - не надо отключать что-то нужное, о чем вы потом будете думать: "почему оно не работает?".

Подробнее об отключении компонентов VMware Tools при развертывании через утилиту командной строки написано тут.

Некоторые функции vCloud Director (VCD) по работе с виртуальными машинами по-прежнему недоступны через стандартные командлеты PowerCLI, поэтому к ним необходимо обращаться через VCD API.

Jon Waite в своем блоге опубликовал PowerCLI-сценарий, с помощью которого можно обратиться к VCD API и увеличить размер загрузочного диска ВМ. Надо сказать, что при подобного рода манипуляциях (как увеличение, так и уменьшение диска) всегда есть риск потери данных, поэтому обязательно сделайте резервную копию.

Собственно, сам скрипт (исходник доступен тут):

Комментарии от автора:

После выполнения сценария нужно будет, само собой, расширить соответствующий раздел гостевой системы. Современные версии Windows и Linux могут раскатывать существующий раздел на весь размер физического устройства даже без перезагрузки машины.

Пример использования сценария:

PS /> $VM = Get-CIVM -Name 'TestVM01'
PS /> $VM | Update-CIVMBootDisk -NewSizeMB 2048
Disk resize for VM TestVM01 submitted successfully.

При описании новых возможностей VMware vSphere 7 мы рассказывали о функциях платформы, появившихся в результате приобретения VMware компании Bitfusion. Эти возможности позволяют оптимизировать использование графических процессоров GPU в пуле по сети, когда vGPU может быть частично расшарен между несколькими ВМ. Это может применяться для рабочих нагрузок задач AI/ML (например, для приложений, использующих PyTorch и/или TensorFlow).

Все это позволяет организовать вычисления таким образом, что хосты ESXi с аппаратными модулями GPU выполняют виртуальные машины, а их ВМ-компаньоны на обычных серверах ESXi исполняют непосредственно приложения. При этом CUDA-инструкции от клиентских ВМ передаются серверным по сети.

Технология эта называлась FlexDirect, теперь это продукт vSphere Bitfusion:

На днях это продукт стал доступен для загрузки и использования в онпремизных инфраструктурах.

Ключевыми особенностями vSphere Bitfusion являются:

• Возможность динамической привязки GPU к любой машине в датацентре, по аналогии с тем, как вы привязываете к ней хранилище.
• Возможность использования ресурсов GPU как одной машине, так и разделения его между несколькими. При этом администратор может выбрать, какой объем Shares выделить каждой из машин, то есть можно приоритизировать использование ресурсов GPU между потребителями.
• Возможность предоставления доступа как по TCP/IP, так и через интерфейс RDMA, который может быть организован как подключение Infiniband или RoCE (RDMA over Converged Ethernet). О результатах тестирования такого сетевого взаимодействия вы можете почитать тут.
• Передача инструкций к серверным машинам и обратно на уровне CUDA-вызовов. То есть это решение не про передачу содержимого экрана как VDI, а про высокопроизводительные вычисления.
• Прозрачная интеграция - с точки зрения приложений менять в инфраструктуре ничего не нужно.

Для управления инфраструктурой доставки ресурсов GPU используется продукт vSphere Bitfusion Manager, который и позволяет гибко распределять ресурсы между потребителями. Раньше он выглядел так:

Теперь же он интегрирован в vSphere Client как плагин:

Архитектура Bitfusion позволяет разделить виртуальную инфраструктуру VMware vSphere на ярусы: кластер GPU, обсчитывающий данные, и кластер исполнения приложений пользователей, которые вводят данные в них и запускают расчеты. Это дает гибкость в обслуживании, управлении и масштабировании.

С точки зрения лицензирования, решение vSphere Bitfusion доступно как аддон для издания vSphere Enterprise Plus и лицензируется точно так же - по CPU. Для других изданий vSphere, увы, этот продукт недоступен.

Скачать vSphere Bitfusion можно по этой ссылке. Документацию можно найти на странице продукта. Также Bitfusion интегрирован с инфраструктурой vSphere with Kubernetes, о чем можно почитать вот в этом документе.

Многие администраторы VMware vSphere знают, что иногда в виртуальной инфраструктуре может возникнуть ситуация APD (All Paths Down). Это состояние, когда хост-сервер ESXi не может получить доступа к устройству ни по одному из путей, а также устройство не дает кодов ответа на SCSI-команды. При этом хост не знает, в течение какого времени будет сохраняться такая ситуация.

Типичный пример - отказ FC-коммутаторов в фабрике или выход из строя устройства хранения. В этом случае хост ESXi будет периодически пытаться обратиться к устройству (команды чтения параметров диска) через демон hostd и восстановить пути. В этом случае демон hostd будет постоянно блокироваться, что будет негативно влиять на производительность. Этот статус считается временным, так как устройство хранения или фабрика могут снова начать работать, и работа с устройством возобновится.

При настройке механизма VMware vSphere HA на уровне кластера у вас есть следующие опции реагирования на такую ситуацию:

• Disable - ничего не делать с виртуальными машинами
• Issue Event - ничего не делать, но сгенерировать событие
• Power Off / Restart – Conservative
• Power Off / Restart – Aggressive

Последние два варианта - Conservative и Aggressive - не очень ясны. Отличие между ними заключается в том, что в консервативном (Conservative) сценарии механизм VMCP (VM Component Protection) сработает только тогда (выключит ВМ), когда убедится, что виртуальные машины могут быть перезапущены на других хостах кластера. В этом случае ESXi убеждается, что связь с другими хостами есть и у них есть доступ к хранилищу ВМ.

В случае политики Aggressive виртуальные машины будут выключены в любом случае, даже если хост не может убедиться, что они могут быть перезапущены на других хостах кластера. Это может произойти в случае полного распада сети, когда хосты ESXi не видят друг друга по сетям сервисной консоли и сети хранения данных. Но если ESXi точно знает, что машины не перезапустятся на других хостах, то и в случае Aggressive он не будет выключать ВМ. То есть выбор всегда делается в пользу наибольшей доступности виртуальных машин.

Иногда, конечно, лучше убить процесс виртуальной машины, если вы попадаете в ситуацию неопределенности в кластере. Ведь лучше выключить машину, чем иметь от нее подтверждения записи на диск, хотя фактически этой записи не происходит. Если вы хотите минимизировать вероятность поддержания таких ВМ в рабочем состоянии для приложений, когда их хранилище отвалилось полностью, вы можете добавить вот такую настройку vSphere HA для всего кластера:

das.restartVmsWithoutResourceChecks = true

Источник.

Не все администраторы знают, что при апгрейде VMware ESXi на более новую мажорную версию есть возможность сохранить предыдущую конфигурацию гипервизора для возможности отката в случае неудачного обновления. Такая возможность, например, есть при апгрейде ESXi 6.5 на версию 6.7.

Для этого нужно во время установки выбрать пункт "Upgrade ESXi, preserver VMFS datastore". Под датастором тут имеется в виду, что на нем сохранится предыдущая установка ESXi:

Кстати, как видно из скриншота, можно сделать и свежую установку ESXi с возможностью отката к предыдущей версии.

Сделать апгрейд на ESXi 7 с сохранением предыдущей версии платформы не выйдет - в VMware vSphere 7 поменялась структура разделов гипервизора ESXi.

Итак, вы сделали апгрейд ESXi, но что-то пошло не так. Например, ваше железо больше не поддерживается (к примеру, CPU), и вам надо сделать откат к прошлой версии ESXi. Для этого во время загрузки вам нужно нажать комбинацию клавиш Shift + <R>:

После этого можно будет выбрать предыдущую версию ESXi и заменить ей новую установку, полностью откатившись к прошлому гипервизору и его настройкам:

Также можно делать бэкап и восстановление конфигурации VMware ESXi - об этом рассказано в KB 2042141.

Многие администраторы платформы VMware vSphere после выхода седьмой версии продукта обнаружили, что ESXi 7.0 больше не хочет устанавливаться на старом оборудовании. Так происходит с каждой версией VMware vSphere - старые драйверы убирают, новые добавляют - это нормальный цикл жизни и развития продуктов. Например, больше не поддерживаются следующие процессоры:

• Intel Family 6, Model = 2C (Westmere-EP)
• Intel Family 6, Model = 2F (Westmere-EX)

Однако для тех, кому очень надо, компания VMware оставила небольшую возможность все-таки установить ESXi 7.0 на старом железе со старыми процессорами, но без каких-либо гарантий по работоспособности и поддержке (то есть, статус у этого режима - unsupported). В частности, коллеги написали статью об установке vSphere 7 на сервер IBM M3 X3550 Series.

Для начала решили ставить ESXi на USB-диск, так как RAID-контроллер сервера больше не поддерживается со стороны ESXi 7:

Далее при загрузке установщика ESXi с CD-ROM или ISO нужно нажать комбинацию клавиш Shift + <O> (это буква, а не ноль), после чего появится приглашение ко вводу. Надо ввести вот такую строчку в дополняемую строку:

allowLegacyCPU=true

Далее для установки выбрали USB-диск и начали установку ESXi на него:

После того, как ESXi установится на ваш сервер, вам нужно будет снова нажать Shift + <O> и повторно вбить указанный выше параметр при первом запуске:

Теперь нужно сделать так, чтобы данный параметр добавлялся при каждой загрузке ESXi. Сначала включим сервисы командной строки ESXi и удаленного доступа по SSH. Для этого нужно запустить службы TSM и TSM-SSH на хосте ESXi:

Далее подключаемся к ESXi по SSH и с помощью следующей команды находим файл конфигурации загрузки:

find / -name "boot.cfg

Далее добавляем в него параметр allowLegacyCPU=true в разделе kernelopt:

Два загрузочных модуля ESXi находятся в директориях /bootbank и /altbootbank. На всякий случай надо поменять boot.cfg в обеих директориях.

С помощью команды cat выведите содержимое отредактированных файлов, чтобы убедиться, что параметры загрузки у вас будут сохраняться:

Ну и, собственно, сам сервер ESXi 7.0.0, нормально работающий на сервере IBM x3550 M3:

Бонусом шутка про редактор vi, которым редактировался файл boot.cfg:

Как вы знаете, в продуктовой линейке VMware есть два решения, предназначенных для виртуализации сетей и централизованного управления сетевым взаимодействием виртуальных машин на уровне всего датацентра - это продукты NSX-T и NSX-V.

NSX-T предназначен для гибридных окружений, как в смысле поддержки разных гипервизоров (ESXi и KVM), так и в плане поддержки облачных инфраструктур (например, AWS). Решение NSX-V разработано специально для виртуальной среды VMware vSphere и использует виртуальные коммутаторы vSphere Distributed Switch (vDS). Оба решения могут быть использованы под одной лицензией, что дает пользователям гибкость при выборе нужного типа развертывания.

(картинка отсюда)

Давайте взглянем на сравнительную таблицу двух версий решений VMware NSX, где собраны основные ключевые отличия:

Ну и вот обзорное видео об основных отличиях NSX-T и NSX-V:

На сайте проекта VMware Labs очередное обновление - новая версия утилиты vSphere Software Asset Management Tool 1.2. Напомним, что средство vSAM предназначено для сбора подробной информации об инсталляции VMware vSphere на вашей площадке, касающуюся лицензий - инвентаря и доступных лицензий. О прошлой версии vSAM мы писали вот тут (там появилась поддержка vSphere 7).

Посмотрим на новые возможности vSAM 1.2:

• Отображение в отчете информации об инфраструктуре кластеров хранилищ vSAN
• Можно открытым текстом выводить лицензионные ключи в отчете, если выставлена соответствующая опция
• В отчет добавлена таблица License Inventory

Скачать vSphere Software Asset Management Tool 1.2 можно по этой ссылке.

Если вы следите за обновлениями VMware vSphere 7, то наверняка знаете, что не так давно уже выходили минорные обновления vCenter 7.0 Update 0a и vSphere with Kubernetes.

На днях VMware выпустила еще один небольшой апдейтик - vCenter 7.0.0b (на момент написания заметки дистрибутив еще недоступен для скачивания).

Давайте посмотрим, что там появилось нового:

• Новые алармы: vCenter Server 7.0.0b получил еще один аларм для vCenter Server Appliance, который срабатывает в случае, когда состояние репликации меняется на READ_ONLY. Аларм гасится, если состояние возвращается в Normal. С помощью этого аларма легко обнаружить проблемы в репликации между узлами vCenter на одной или нескольких площадках.
• C vCenter Server 7.0.0b можно использовать кнопку "Show only rollup updates", позволяющую отфильтровать и выбрать патчи, которые вы хотите включить в бейслайн для vSphere Lifecycle Manager. Кнопка доступна на вкладке Updates панели Lifecycle Manager. Также эта опция доступна в мастере создания нового бейслайна.
• Решено несколько проблем и исправлены некоторые ошибки. Посмотреть информацию о них можно тут.
• Про обновления движка VMware vSphere with Kubernetes рассказано здесь.

Скачать VMware vCenter 7.0.0b в составе vSphere 7 можно по этой ссылке.

Мы уже очень много писали о нововведениях VMware vSphere 7, но все еще есть о чем рассказывать. Не так давно мы говорили об улучшениях горячей миграции виртуальных машин vMotion в ESXi 7 (и тут), а сегодня посмотрим, как был улучшен механизм горячей миграции хранилищ Storage vMotion.

При миграциях SVMotion используется техника Fast Suspend and Resume (FSR), которая очень близка к vMotion, но не идентична ему. При горячей миграции хранилища ВМ происходит создание теневой копии этой машины на том же хосте ESXi, куда подцепляются новые хранилища или устройства, после чего происходит копирование метаданных памяти и состояния устройств от исходной ВМ к целевой. В этот момент машина "замирает" примерно на 1 секунду, а затем происходит включение уже целевой ВМ, а исходная ВМ выключается и удаляется:

Такая же методика применяется и для механизма Hot Add / Remove, который позволяет добавлять и удалять устройства виртуальной машины "на горячую" без необходимости ее выключения. Для выключенной ВМ добавление и удаление устройств - это лишь изменения в конфигурационном файле VMX.

Сам процесс FSR в целом работал довольно неплохо для небольших виртуальных машин, а прерывание работы ВМ укладывалось, как правило, в одну секунду. Но для больших машин (Monster VM) процесс копирования метеданных памяти мог занять продолжительное время.

Во время приостановки ВМ происходит копирование блоков памяти Page Frames (PFrames), представляющих собой маппинги между виртуальной памятью машины и физическими адресами Machine Page Numbers (MPN).

Эти блоки и нужно скопировать во время паузы FSR:

До VMware vSphere 7 во время копирования метаданных памяти использовался только один vCPU машины, в то время как остальные процессоры ВМ ждали окончания процесса и простаивали:

Очевидно, что для больших машин с большим объемом памяти и числом vCPU процесс работал неоптимально. В VMware vSphere 7 для копирования блоков PFrame используются все vCPU. Метаданные памяти разделяются на сегменты, и за копирование каждого сегмента отвечает свой виртуальный процессор. Сам процесс копирования происходит в параллельном режиме, что существенно экономит время на копирование:

Для обычных ВМ это улучшение вряд ли получится почувствовать на практике, но если вы используете Monster VMs, то эффект от обновленного FSR можно будет заметить. Например, VMware взяла машину с 1 ТБ памяти и 48 vCPU, которую перемещала под нагрузкой с помощью Storage vMotion. Так вот время переключения со старым FSR составило 7.7 секунды, а с новым - около 0.5 секунды для VMware vSphere 7:

На портале VMware Learning появились новые лабы (они же Hands-on Labs), которые посвящены новой версии платформы VMware vSphere 7:

Напомним, что лабораторные работы VMware HoL позволяют освоить работу с различными продуктами и технологиями, проходя по шагам интерфейса. Такой способ отлично подходит для обучения работе с новыми версиями решений без необходимости их развертывания.

На данный момент доступны следующие лабы:

• HOL-2111-01-SDC – VMware vSphere – What’s New
• HOL-2111-02-SDC – VMware vSphere – Advanced Topics
• HOL-2111-03-SDC – VMware vSphere – Security Getting Started

В этих лабораторных работах содержится около трех часов контента, с помощью которого вы сможете узнать обо всех нововведениях vSphere 7 в деталях. Скоро также обещают и лабы по vSphere 7 with Kubernetes, что будет очень полезно, так как многие пользователи не могут попробовать контейнеризованные приложения в своей виртуальной инфраструктуре.

Также уже довольно давно доступна лаба VMware Cloud Foundation 4 Hands-on Lab - напомним, что архитектура VCF 4 также построена на базе VMware vSphere 7.

Мы много писали о возможностях новой версии платформы VMware vSphere 7 (например, тут и тут), но нововведений там столько, что это не уместить и в десять статей. Сегодня мы поговорим об изменениях в структуре разделов (Partition Layout), которые произошли в VMware ESXi 7.

Первое, что надо отметить, что до vSphere 7 разделы были фиксированного объема, а их нумерация была статической, что ограничивало возможности по управлению ими, например, в плане поддержки больших модулей, функций отладки и стороннего ПО.

Поэтому в vSphere 7 были увеличены размеры загрузочных областей, а системные разделы, которые стали расширяемыми, были консолидированы в один большой раздел.

В VMware vSphere 6.x структура разделов выглядела следующим образом:

Как мы видим, размеры разделов были фиксированы, кроме раздела Scratch и опционального VMFS datastore. Они зависят от типа загрузочного диска (boot media) и его емкости.

В VMware vSphere 7 произошла консолидация системных разделов в область ESX-OSData:

Теперь в ESXi 7 есть следующие 4 раздела:

• System boot - хранит boot loader и модули EFI. Формат: FAT16.
• Boot-banks (2 штуки) - системное пространство для хранения загрузочных модулей ESXi. Формат: FAT16.
• ESX-OSData - унифицированное хранилище дополнительных модулей, которые не необходимы для загрузки. К ним относятся средства конфигурации и сохранения состояния, а также системные виртуальные машины. Формат: VMFS-L. Для этой области нужно использовать долговременные хранилища на базе надежных устройств.

Как вы видите, ESX-OSData разделен на две части: ROM-data и RAM-data. Часто записываемые данные, например, логи, трассировка томов VMFS и vSAN EPD, глобальные трассировки, горячие базы данных - хранятся в RAM-data. В области ROM-data хранятся нечасто используемые данные, например, ISO-образы VMware Tools, конфигурации, а также дампы core dumps.

В зависимости от размера устройства, куда устанавливается ESXi, меняется и размер всех областей, кроме system boot:

Если размер устройства больше 128 ГБ, то ESXi 7 автоматически создает VMFS-тома.

Когда вы используете для запуска ESXi устройства USB или карточки SD, то раздел ESX-OSData создается на долговременном хранилище, таком как HDD или SSD. Когда HDD/SSD недоступны, то ESX-OSData будет создан на USB-устройстве, но он будет содержать только ROM-data, при этом RAM-data будет храниться на RAM-диске (и не сохранять состояние при перезагрузках).

Для подсистем ESXi, которым требуется доступ к содержимому разделов, используются символьные ссылки, например, /bootbank и /altbootbank. А по адресу /var/core лежат дампы core dumps:

В VMware vSphere Client можно посмотреть информацию о разделах на вкладке Partition Details:

Ту же самую информацию можно получить и через интерфейс командной строки ESXi (команда vdf):

Обратите внимание, что соответствующие разделы смонтированы в BOOTBANK1 и 2, а также OSDATA-xxx.

Кстати, вы видите, что OSDATA имеет тип файловой системы Virtual Flash File System (VFFS). Когда OSDATA размещается на устройствах SDD или NVMe, тома VMFS-L помечаются как VFSS.

ESXi поддерживает множество устройств USB/SD, локальных дисков HDD/SSD, устройств NVMe, а также загрузку с тома SAN LUN. Чтобы установить ESXi 7 вам нужно выполнить следующие требования:

• Boot media размером минимум 8 ГБ для устройств USB или SD
• 32 ГБ для других типов устройств, таких как жесткие диски, SSD или NVMe
• Boot device не может быть расшарен между хостами ESXi

Если вы используете для установки ESXi такие хранилища, как M.2 или другие не-USB девайсы, учитывайте, что такие устройства могут быстро износиться и выйти из строя, например, если вы используете хранилища VMFS на этих устройствах. Поэтому удалите тома VMFS с таких устройств, если они были созданы установщиком по умолчанию.

Как вы знаете, компания VMware выпустила платформу VMware vSphere 7 в начале апреля этого года после громкого анонса месяцем ранее. В конце апреля VMware опубликовала интересную новость с результатами исследования среди пользователей, которые тестировали бета-версию vSphere 7 и потом прошли опрос, где одним из вопросов был "Почему бы вы хотели обновиться?". Собственно, вот его результаты...

Некоторым администраторам может понадобиться PowerCLI-сценарий, с помощью которого можно подсчитать число гостевых операционных систем в виртуальных машинах инфраструктуры VMware vSphere. Stuart в своем блоге рассказал про интересный скрипт, с помощью которого это можно сделать.

Начал он с того, что в переменную $server2012 он записал количество гостевых операционных систем определенного типа с помощью команды:

$server2012 = ((get-vm).extensiondata.guest | Where GuestFullName -eq "Microsoft Windows Server 2012 (64-bit)").count

Далее он стал думать, как сделать таблицу со всеми ОС, для этого решил создать хэш-таблицу, куда будут записываться типы гостевых ОС и их количество:

$OS_hashtable = $null

$OS_hashtable = @{}

$VMs = Get-VM

foreach ($VM in $VMs){
    $OSName = $VM.ExtensionData.Guest.GuestFullName
    If(!($OS_hashtable.ContainsKey($OSName))){
        $OS_hashtable.add($OSName,0)
    }
    $Value = $OS_hashtable.$OSName
    $NewValue = $Value + 1
    $OS_hashtable[$osName] = $NewValue
}
$OS_hashtable | FT -AutoSize

Далее у него получился вот такой результат:

В этой таблице все в порядке, кроме последней строчки - в нее набиваются гостевые ОС, для которых тип не был обнаружен. Поэтому автор добавил следующие строчки с именами ВМ, чтобы добавить значение Unknown таким машинам:

# Added this to the beginning of the script

  $NullOS = Get-Content C:\Scripts\Logs\Guestfullname.txt

# Added this to the foreach loop section

  IF ($OSName -eq $NullOS){$OSName = "Unknown"}

Итоговый скрипт получился таким:

$debug = $false
$OS_hashtable = $null
$OS_hashtable = @{}
$NullOS = Get-Content C:\Scripts\Logs\Guestfullname.txt
$VMs = Get-VM
Foreach ($VM in $VMs){
    $OSName = $VM.ExtensionData.Guest.GuestFullName
    IF ($OSName -eq $NULL){$OSName = $VM.ExtensionData.Config.GuestFullName}
    IF ($OSName -eq $NullOS){$OSName = "Unknown"}
    IF ($debug){write-host "$VM - $OSName"}
    If(!($OS_hashtable.ContainsKey($OSName))){
        $OS_hashtable.add($OSName,0)
    }
    $Value = $OS_hashtable.$OSName
    $NewValue = $Value + 1
    $OS_hashtable[$osName] = $NewValue
}
$OS_hashtable | FT -AutoSize

Компания VMware выпустила на днях обновление одного из самых главных своих документов - "Performance Best Practices for VMware vSphere 7.0". Мы не зря в заголовке назвали это книгой, так как данный документ представляет собой всеобъемлющее руководство, где рассматриваются все аспекты поддержания и повышения производительности новой версии платформы VMware vSphere 7.0 и виртуальных машин в контексте ее основных возможностей.

На 96 листах очень подробно описаны лучшие практики для администраторов платформы и гостевых ОС:

Вот все корневые разделы этого руководства:

• Persistent memory (PMem), including using PMem with NUMA and vNUMA
• Getting the best performance from NVMe and NVME-oF storage
• AMD EPYC processor NUMA settings
• Distributed Resource Scheduler (DRS) 2.0
• Automatic space reclamation (UNMAP)
• Host-Wide performance tuning (aka, “dense mode”)
• Power management settings
• Hardware-assisted virtualization
• Storage hardware considerations
• Network hardware considerations
• Memory page sharing
• Getting the best performance from iSCSI and NFS storage
• vSphere virtual machine encryption recommendations
• Running storage latency-sensitive workloads
• Running network latency-sensitive workloads
• Network I/O Control (NetIOC)
• DirectPath I/O
• Microsoft Virtualization-Based Security (VBS)
• Selecting virtual network adapters
• vCenter database considerations
• The vSphere HTML5 Client
• VMware vSphere Lifecycle Manager
• VMware vSAN performance

Для администраторов больших инфраструктур, активно внедряющих новые технологии (например, хранилища с Persistent Memory или DRS 2.0), появилось много всего нового и интересного, поэтому с книжкой нужно хотя бы ознакомиться по диагонали, останавливаясь на новых функциях ESXi 7 и vCenter 7.

Скачать PDF-версию "Performance Best Practices for VMware vSphere 7.0" можно по этой ссылке.

Компания VMware объявила о том что продляет поддержку (General Support) для платформы VMware vSphere версии 6.7 до 15 октября 2022 года. Напомним, что ранее эта поддержка была заявлена до 15 ноября 2021 года. Таким образом, срок действия поддержки General Support был продлен на 11 месяцев.

General Support Phase - эта фаза начинается после выпуска мажорного релиза (GA) и длится довольно долгое время. В этот период пользователи, купившие официальную поддержку VMware (а не купить ее нельзя), получают апдейты и апгрейды, багофиксы и исправления безопасности, а также техническое сопровождение в соответствии с Terms and Conditions.

Дата наступления EoTG (End of Technical Guidance) останется неизменной - это 15 ноября 2023 года. В рамках этой фазы, которая начинается с момента окончания General Support, предоставляются инструкции через портал самообслуживания, а по телефону звонки уже не принимаются. В этой фазе можно открыть кейс в техподдержке онлайн, но только для поддерживаемых конфигураций. В этой фазе VMware не оказывает поддержки, касающейся оборудования, обновлений ОС, патчей безопасности или багофиксов (если о другом не объявлено дополнительно). Предполагается, что в этой фазе пользователи используют стабильные версии ПО и конфигураций при нормальных (не повышенных) нагрузках.

Более подробно о сроках поддержки и Technical Guidance для продуктов VMware можно прочитать в документе "VMware Lifecycle Product Matrix".

Как знает большинство администраторов VMware vSphere, у данной платформы есть очень удобная сущность Content Library, которая позволяет хранить контент различного типа (скрипты, ISO-образы, текстовые файлы), в том числе шаблоны виртуальных машин. В обновленном решении VMware vSphere 7 появилось несколько новых возможностей по работе с библиотеками, о которых мы рассказывали вкратце, а сегодня поговорим подробнее.

Первое важное нововведение - представление для управления шаблонами, в котором доступны функции Check-In и Check-Out для работы с версиями шаблонов и возможностью откатиться к предыдущей версии.

Ранее при работе с шаблонами в формате VM Template (*.vmtx) администратор vSphere должен был выполнить следующую последовательность действий:

• Конвертировать шаблон в виртуальную машину
• Сделать снапшот ВМ на случай того, что что-то пойдет не так
• Обновить гостевую ОС или другие настройки ВМ
• Конвертировать ВМ назад в шаблон
• Скопировать шаблон обратно в Content Library
• Удалить старый шаблон из библиотеки

Теперь это все выглядит гораздо проще. Для внесения изменений в шаблон нужно сделать просто Check-Out его из библиотеки:

Этот процесс вовлекает последовательность действий, но даже во время нее можно развертывать новые ВМ из этого шаблона (просто остальные пользователи не могут сделать Check-Out).

Далее администратор может изменять шаблон и чекинить его обратно в библиотеку, а также создавать новые версии этого шаблона, чтобы можно было использовать несколько модификаций одного шаблона. Также при Check-In шаблона можно указать, что в нем изменилось, чтобы другие пользователи были в курсе:

После этого создается цепочка версий с временными метками, где можно отслеживать всю историю изменений шаблона ВМ:

Версионирование позволяет откатиться к любой версии шаблона, а также удалить ее из цепочки:

Кроме того, теперь у Content Library появились расширенные настройки (Advanced Configuration), доступ к которым можно получить вот тут:

Сами настройки выглядят так (можно выбрать один из серверов vCenter, где изменяются настройки):

Обратите внимание, что для применения некоторых настроек нужно будет перезагрузить сервис Content Library. Делается это из интерфейса vCenter Appliance Management Interface (VAMI). Для этого вас перенаправят на страницу https://<vCenterServer-FQDN>:5480:

Также в vSphere 7 был улучшен механизм привилегий для библиотек контента:

Ну и напоследок отметим, что еще в PowerCLI 11.5 появилось несколько новых командлетов для управления библиотеками контента. В PowerCLI 12 все еще лучше.

Мы много писали о новых возможностях платформы VMware vSphere 7, но невозможно рассказать обо всех ее нововведениях в одной статье. Сегодня мы расскажем об одной интересной штуке - компоненте Watchdog Timer, который мы упоминали в одном предложении в статье о новых фичах.

Теперь для виртуальных машин доступно специальное устройство virtual watchdog timer (vWDT), которое позволяет администраторам в унифицированном виде узнавать о том, что гостевая операционная система и приложения данной ВМ зависли или вывалились в синий экран. Это особенно важно для кластеризованных приложений в целях поддержания их доступности.

В случае если гостевая ОС и приложения зависли, Watchdog позволяет обнаружить это и среагировать определенным образом, например, перезагрузить машину. Для этого есть механизм таймера обратного отчета, который должен сбрасываться в нормальном режиме функционирования системы.

Это виртуальное устройство пробрасывается в гостевую ОС через механизм BIOS/EFI ACPI и настраивается на уровне гостевой системы или самого BIOS/EFI.

Таблица Watchdog Resource Table (WDRT) имеет несколько регистров, в которые можно записать значения таймера, действия по их истечению и другие параметры. Большинство современных ОС поддерживают интеграцию с таблицей Watchdog Action Table (WDAT), определяющей список доступных действий для таймеров, которые и использует компонент WDRT.

Вот список доступных инструкций WDAT:

• WATCHDOG_ACTION_RESET
• WATCHDOG_ACTION_QUERY_CURRENT_COUNTDOWN_PERIOD
• WATCHDOG_ACTION_QUERY_COUNTDOWN_PERIOD
• WATCHDOG_ACTION_SET_COUNTDOWN_PERIOD
• WATCHDOG_ACTION_QUERY_RUNNING_STATE
• WATCHDOG_ACTION_SET_RUNNING_STATE
• WATCHDOG_ACTION_QUERY_STOPPED_STATE
• WATCHDOG_ACTION_SET_STOPPED_STATE
• WATCHDOG_ACTION_QUERY_REBOOT
• WATCHDOG_ACTION_SET_REBOOT
• WATCHDOG_ACTION_QUERY_SHUTDOWN
• WATCHDOG_ACTION_SET_SHUTDOWN
• WATCHDOG_ACTION_QUERY_WATCHDOG_STATUS
• WATCHDOG_ACTION_SET_WATCHDOG_STATUS

Для большинства современных серверных ОС Windows и Linux не требуется каких-либо действий для дополнительной настройки таймера, но они могут понадобиться для некоторых старых систем, а FreeBSD или Mac OS X вовсе не поддерживают Watchdog Timer. Вот в целом информация о его поддержке:

• Windows 2003 поддерживает Watchdog Resource Table (WDRT)
• Windows 2008 и более поздняя поддерживает Watchdog Action Table (WDAT). Гостевая ОС не требует дополнительной конфигурации.
• Linux-дистрибутивы, такие как Ubuntu 18.04 и Red Hat Enterprise Linux 7.6, на базе ядра 4.9 или более позднего поддерживают Watchdog Action Table (WDAT). Для этого нужен драйвер wdat_wdt.ko.

Для настройки вам понадобится виртуальная машина с VM hardware версии 17 (появилось в vSphere 7). Надо просто добавить устройство Watchdog Timer:

Как вы видите, виртуальный Watchdog Timer можно включить либо на уровне BIOS/EFI (тогда он будет запускаться до старта ОС), либо на уровне гостевой ОС. Помните, что если гостевая ОС не поддерживает это устройство, то машина будет постоянно перезапускаться по команде от устройства Watchdog.

В vSphere Client видна информация о статусе исполнения Watchdog Timer. Не запущен:

Запущен:

Не так давно мы писали о новом релизе архитектуры VMware Cloud Foundation 4.0, которая представляет собой комплексное программное решение, включающее в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия под управлением SDDC Manager.

В рамках новой версии VCF 4.0 была анонсирована поддержка архитектуры контейнеров приложений в виртуальных средах VMware vSphere with Kubernetes (ее эволюцией является нативная платформа Project Pacific). С этого момента, чтобы обеспечить поддержку контейнеров, пользователям VCF приходилось иметь минимум 7 серверов - 4 сервера для домена управления VCF Management Domain и 3 сервера для Virtual Infrastructure (VI) Domain.

Теперь домен VI можно размещать в рамках домена VCF Management, что сокращает число минимально необходимых хостов до четырех:

Таким образом, теперь VCF поддерживает 2 архитектуры:

• Consolidated architecture - один кластер vSphere развертывается как часть Management Domain. Пулы ресурсов позволяют изолировать управляющие нагрузки (экземпляры vCenter, NSX Manager, SDDC Manager и т.п.) от нагрузок виртуальных машин. В этом случае нужно минимум 4 хоста для управляющего домена.
• Standard architecture - управляющие нагрузки и виртуальные машины исполняются на разных хостах в разных доменах рабочей нагрузки. ВМ развертываются в отдельных кластерах vSphere, которые работают в рамках доменов Virtual Infrastructure (VI) domains. Это позволяет не только отделить среды на физическом уровне, но и разнести их по разным окружениям разных экземпляров vCenter. Такая архитектура считается рекомендуемой. В рамках окружения VCF можно развернуть до 14 доменов VI и один Management Domain, каждый домен может иметь несколько кластеров в vSphere (в каждом кластере минимум 3 хоста).

Более подробно об этой поддержке написано в документе "VMware vSphere with Kubernetes support on the VMware Cloud Foundation Management Domain".

Для платформы VMware vSphere 7 вышло первое обновление - стал доступен для скачивания апдейт управляющего сервера VMware vCenter 7.0 Update 0a.

Цифра 0 в номере апдейта намекает на то, что ничего особо нового в обновлении нет, что соответствует действительности - было исправлено лишь несколько мелких ошибок и одна важная.

Она заключалась в том, что vSphere Lifecycle Manager и службы vSAN File Services не могли быть одновременно включены в кластере. Если вы включали что-то из этого первым, то второй компонент не мог быть включен после этого (они не были совместимы между собой). Теперь это поправили - и они вполне работают вместе.

Скачать VMware vCenter 7.0 Update 0a можно по этой ссылке.

Помимо этого, были обновлены и службы VMware vSphere with Kubernetes, включающие в себя виртуальный модуль Tanzu Kubernetes clusters OVA. Из нового там появилось:

• Службы Tanzu Kubernetes Grid Service for vSphere:
  • Пользователи могут накатывать последовательные обновления rolling upgrades на узлы worker nodes и control plane nodes для Kubernetes Grid Service for vSphere и апгрейдить службы pvCSI, Calico и authsvc. Также для этих компонентов предусмотрены процедуры пре-чеков перед апгрейдом.
  • Последовательные обновления rolling upgrades могут быть использованы для одновременного с апгрейдом изменения класса ваших узлов на больший или меньший по размеру.
• Для Supervisor cluster поддерживаются новые версии Kubernetes с возможностью апгрейда:
  • Kubernetes 1.17.4
  • С версии Kubernetes 1.16.x можно обновиться на 1.17.x

Как все уже знают, в новой версии платформы виртуализации VMware vSphere 7 средство обновления виртуальной инфраструктуры VMware Update Manager (VUM) уступило место новому продукту - VMware Lifecycle Manager.

Ранее администраторы vSphere использовали VUM для обновлений серверов ESXi и драйверов, а утилиты от производителей серверов - для обновления их микрокода (firmware). Теперь эти процессы объединяются в единый механизм под управлением vSphere Lifecycle Manager.

На сайте buildvirtual.net появился обзор процесса апгрейда хост-серверов ESXi на версию 7.0, который мы приводим ниже, чтобы дать понимание того, что сам процесс, в плане накатывания апгрейда, от VUM почти ничем не отличается.

Итак, сначала надо импортировать ISO-образ в Lifecycle Manager. Запускаем его в vSphere Client и переходим в раздел Imported ISOs:

Нажимаем Import ISO и указываем ISO-образ ESXi 7.0, который скачали с сайта VMware:

После этого данный образ появится в списке:

Затем надо создать бейслайн с этим образом. Нажимаем ссылку New Baseline, где далее указываем тип содержимого Upgrade:

Выбираем образ, который мы хотим привязать к бейслайну:

После этого созданный бейслайн нужно привязать к хостам или кластеру. Для этого выбираем пункт Attach Baseline or Baseline Group:

После успешной привязки к кластеру, жмем кнопку Check Compliance, которая запускает проверку соответствия хостов заданному бейслайну. В итоге мы увидим, например, что 4 хоста находятся в статусе non-compliant, то есть им можно накатить апгрейд (в данном случае - с версии 6.7 на 7.0):

Перед запуском апгрейда нужно выполнить Remediation Pre-Check, чтобы проверить, что в кластере нет препятствий для апгрейда хостов на седьмую версию.

Если ничего критичного не нашлось, жмем на кнопку Remediate:

Это, собственно, запустит сам процесс апгрейда. Вам нужно будет лишь согласиться с EULA и запустить процедуру обновления. После успешного апгрейда будет показано, что все хосты были обновлены:

В консоли вы увидите, что ESXi 7.0 установлен:

То же самое будет и в vSphere Client:

Как видно из описаний шагов, процесс апгрейда с помощью Lifecycle Manager практически ничем не отличается от оного с помощью Update Manager.

Вильям Лам написал интересную заметку о том, как пробросить USB-клавиатуру или мышь хоста ESXi (они называются USB HID Devices) в гостевую ОС виртуальной машины на VMware vSphere.

Такое может понадобиться, например, когда требуется пробросить в конкретную ВМ отдельную пару USB-устройств ввода (клавиатура+мышь), помимо выделенного устройства vGPU. Также некоторые другие устройства (например, датчики температуры) также притворяются HID-девайсами. Хост ESXi в этом случае по умолчанию не считает необходимым подцеплять такие устройства никуда.

Это поведение можно изменить, добавив следующие параметры в VMX-файл виртуальной машины (или ее Advanced Settings):

usb.generic.allowHID = "TRUE"
usb.quirks.device0 = "X:Y allow"

Вторая вещь, которая вам может понадобиться - это проброс USB-устройств Chip Card Interface Devices (CCID) в виртуальную машину (например, ридер смарт-карт). Для этого в VMX нужно добавить следующие строчки:

usb.generic.allowCCID = "TRUE"
usb.quirks.device0 = "X:Y allow"

В обоих этих случаях X - это vendorId, а Y - deviceId (например, выглядит так - 0x03f0:0x0024).

Чтобы узнать эти параметры, нужно выполнить в консоли ESXi команду lsusb.

После добавления указанных настроек виртуальная машина должна увидеть эти USB-устройства с хоста.

Frank Denneman обратил внимание на одну интересную новую функцию VMware vSphere 7 - возможность миграции vMotion для виртуальных машин с привязанными ISO-образами.

Как знают администраторы vSphere, часто приходится привязывать ISO-образ к консоли виртуальной машины, чтобы установить какое-то ПО. Нередко этот ISO находится на локальном хранилище машины администратора:

В таком случае, при попытке миграции vMotion данной виртуальной машины выдается ошибка о невозможности выполнения операции в связи с привязанным и активным локальным ISO к виртуальному устройству CD/DVD:

Усугубляется это еще и тем, что такие машины исключаются из миграций DRS, а также не могут быть смигрированы автоматически при переводе хоста ESXi в режим обслуживания (Maintenance mode). Как это обычно бывает, администратор узнает об этом в самом конце, минут через 10 после начала операции по переводу на обслуживание - и агрится от такой ситуации.

Поэтому в VMware vSphere 7 такое поведение пофиксили: теперь при миграции vMotion виртуальное устройство с локальным файлом отсоединяется от исходной машины по команде процесса VMX, все операции с ним буферизуются, далее происходит миграция машины на другой хост, подцепление к нему виртуального устройства с вашим ISO и накатывание буфера.

После переключения машины на другой хост ESXi, VMRC-консоль показывает подключение вашего локального ISO уже к целевой машине:

Казалось бы, мелочь, но иногда может сэкономить немного времени администратора. Для работы этой фичи нужно, чтобы оба хоста VMware ESXi были седьмой версии или выше.

На сайте проекта VMware Labs появилась обновленная версия мобильного клиента для управления виртуальной инфраструктурой VMware vSphere - vSphere Mobile Client 1.11.

Напомним, что в прошлый раз мы писали о возможностях Mobile Client версии 1.9, поэтому ниже мы посмотрим, что нового появилось в последних двух версиях - 1.10 и 1.11.

• Виртуальная клавиатура для консоли ВМ, включая специальные клавиши. Наконец-то, системные администраторы смогут выполнять простейшие задачи внутри гостевой системы.
• Для кластеров появилась страница с их деталями, чего тоже очень ждали.
• Для iOS-устройств появился прямой доступ к консоли ВМ (по-прежнему, требуется и прямой доступ с устройства к серверу ESXi).
• Хост больше не показывается как Standalone, когда является частью кластера.
• Более корректная обработка статусов для объектов (алармы и проблемы в конфигурации).
• Правильный подсчет vCPU на странице свойств ВМ.
• Все страницы детальной информации об объектах теперь сделаны в едином стиле.
• Улучшена поддержка старых мобильных устройств.
• Исправлено множество ошибок самого разного плана.

Скачать vSphere Mobile Client 1.11 можно по этим ссылкам:

• vSphere Mobile Client for Android devices
• vSphere Mobile Client for iOS devices

Также не забудьте посмотреть инструкцию о развертывании Notification Service (он доступен как Docker-контейнер), чтобы включить Push-уведомления на своих устройствах.

Еще в версии VMware vSphere 6.7 появилась интересная новая возможность платформы виртуализации - перезагрузка гипервизора без рестарта всего хоста ESXi. Очевидно, что главное преимущество такого подхода - уменьшенное время на загрузку серверов, некоторые из которых грузятся ну ооочень долго.

Ведь для некоторых обновлений и патчей необязательно аппаратно перезагружать хост и реинициализировать все его оборудование, что происходит при стандартной загрузке (процесс power-on self-test, POST). Достаточно лишь перезагрузить программную часть платформы.

Возможность быстрой перезагрузки ESXi Quick Boot может быть использована компонентами vSphere Update Manager или vSphere Lifecycle Manager (vLCM). 

Надо отметить, что функции Quick Boot доступны не для всех серверов. Более подробная информация по этому поводу приведена в KB 52477, а вот ссылки на страницы вендоров серверного оборудования, где можно узнать детали поддержки этой технологии:

• Quick boot on Dell EMC
• Quick Boot on HPE
• Quick Boot on Cisco
• Quick Boot on Fujitsu (пока нет ссылки)
• Quick Boot on Lenovo

Для корректной работы Quick Boot есть и некоторые ограничения. Если вы используете vSphere 6.7, то Quick Boot не будет работать, если у вас включен TPM, есть устройства passthru, а также загружены драйверы vmklinux. Для версии vSphere 7.0 ограничением является только включенный TPM.

Для проверки хоста ESXi на совместимость с Quick Boot нужно выполнить следующую команду в консоли (она выведет полный список факторов, препятствующих использованию быстрой загрузки, таких как драйверы, оборудование и т.п.):

/usr/lib/vmware/loadesx/bin/loadESXCheckCompat.py

Включить быструю загрузку можно в настройках Update Manager или Lifecycle Manager через vSphere Client или Web Client (этот клиент доступен только для vSphere 6.7):

Не так давно мы писали о той функциональности, которой уже нет в VMware vSphere 7, а также о том, какие фичи находятся в состоянии Deprecated. Это значит, что они пока еще есть в текущем релизе, но уже точно будут отсутствовать в следующей версии платформы. Одной из таких фич стала аутентификация Integrated Windows Authentication (IWA), она же "встроенная проверка подлинности Windows".

IWA - это механизм, который позволяет аутентифицироваться через встроенную аутентификацию ОС в сервисах сервера vCenter, который подключен к домену Microsoft Windows Active Directory (AD).

Депрекация этого механизма в vSphere 7 означает, что вы все еще можете смигрировать настройки IWA при апгрейде vCenter, а также развернуть его с нуля. После этого IWA позволит пользователям аутентифицироваться на vCenter.

Почему поддержка IWA уходит из vSphere? Ответ прост - раньше vCenter работал на платформе Windows как приложение для этой ОС с соответствующими возможностями доступа к ее функциям и сервисам AD, теперь же это виртуальный модуль (vCenter Server Appliance), который работает на базе Linux (а точнее Photon OS) и не может быть нативной частью домена.

Какие альтернативные способы можно использовать для аутентификации в домене AD:

• С использованием LDAP. Контроллеры домена предоставляют сервисы LDAP, которые может использовать vCenter.
• С использованием нового механизма Identity Federation (появился в версии vSphere 7). Эту возможность можно применять для соединения vCenter к Active Directory Federation Services (ADFS) с использованием протоколов OAUTH2 и OIDC.

VMware также объясняет, что присоединение vCenter к инфраструктурам, которые зависят от этого vCenter, может потенциально создать проблемы зависимостей: контроллер домена зависит от включенного в него vCenter как виртуальная машина, а vCenter зависит от домена как его член.

Еще одна причина депрекации IWA - "политическая". Некоторые крупные организации имеют очень строгие правила для администраторов по заведению новых систем в домен и обслуживанию его жизненного цикла. Нередка ситуация, когда администраторы vSphere, которые имеют право включать vCenter в домен, получают бан аккаунта от безопасников, которые отключают его за неактивность.

Аналогичный подход к депрекации IWA компания VMware сделала и для серверов ESXi - они будут поддерживать взаимодействие с доменом на тех же условиях, что и vCenter. Правами доступа к хост-серверам ESXi можно управлять через стандартный механизм Role-Based Access Controls (RBAC) на сервере vCenter.

Поэтому по совокупности причин было решено отказаться от IWA в пользу более гибкого механизма LDAP/LDAPS.

Кстати, если вы видите в логе контроллера домена событие Event 2889 при использовании IWA, то обратитесь к статье KB 78644.

Чтобы переключиться на новый способ аутентификации нужно вывести серверы из домена по старой схеме и включить интеграцию по новой. Вот, например, видео о том, как смигрировать аутентификацию с LDAP на более защищенный протокол LDAPS:

Перед переходом всей инфраструктуры на новый способ аутентификации нужно обязательно протестировать сам метод в тестовой инфраструктуре. Ну а когда будете делать перевод продакшена, не забудьте сделать снапшот сервера vCenter - если что на него можно будет откатиться с сохранением старых настроек.

Не секрет, что сейчас администраторы виртуальных инфраструктур предпочитают работать с ее компонентами посредством тонких клиентов. Например, в VMware vSphere 7 остался только тонкий клиент на базе HTML5, а старые клиенты на баз C# и Flash уже ушли в прошлое. Лидирующий производитель средств для создания программных и программно-аппаратных хранилищ под виртуализацию - компания StarWind Software - также активно следует этой тенденции...

Компания VMware выпустила небольшие обновления инфраструктуры виртуализации VMware vSphere 6.7 - на днях вышли апдейты vCenter Server 6.7 Update 3g и ESXi 6.7 Update 3 P02.

Более-менее заметные изменения появились только в vCenter 6.7 U3g:

• Появился аларм Replication State Change для виртуального модуля vCSA с Embedded Platform Services Controller, который возникает при переходе репликации между инстансами в статус READ_ONLY. При возвращении в статус Normal аларм исчезает.
• Теперь можно использовать утилиту sso-config для замены сертификата Security Token Service (STS).
• Несколько исправлений ошибок, приведенных в разделе Resolved Issues.
• Обновления Photon OS, о которых можно почитать вот тут.

Обновление ESXi 6.7 Update 3 P02 включает в себя только патчи подсистемы безопасности, а также апдейты драйверов устройств. Более подробно об этом написано вот тут. Скачать это обновление можно через Update Manager или вручную с этой страницы (а далее установить с помощью команды esxcli software vib).